Modern access networks enable broadband connections to be established over the network to permit end users, or subscribers, to achieve fast access to the services provided over the Internet. A popular technology for providing such broadband connections is Digital Subscriber Line (DSL) technology. This permits high data rates to be transmitted over legacy copper connections which are already present in the network (from legacy Plain Old Telephone Services (POTS). More recently, operators have started to provide rate-adaptive services using DSL techniques. In a rate-adaptive DSL mode, the aim is that lines should operate at the maximum rate at which they are capable of operating.
The basic approach for operating in a rate-adaptive mode relies on the fact that in DSL systems, when the DSL connection is being established (or re-established after some break in the connection) a synchronisation process occurs during which the DSL modems on either side of the connection (also referred to as DSL transceiver units, there being a remote end unit and a Central Office end unit—in ADSL systems these may be referred to as an ADSL Transceiver Unit—Remote end (ATU-R) and an ADSL Transceiver Unit—Central office end (ATU-C)) determine a theoretical maximum line rate at which the line could be established based on the levels of noise and signal attenuation, etc. experienced on the line during the synchronisation period and also dependent upon the “profile” upon which the line is operating. The profile sets parameters such as the Signal-to-Noise ratio Margin (SNM) at which the line should operate and the amount of interleaving to be used on the line etc., which parameters affect the stability of the line. The basic approach for performing rate adaptive DSL is then just to set the line to operate at the theoretical maximum line rate determined during the synchronisation process. This can be enhanced somewhat in order to account for the fact that conditions may change somewhat after synchronisation, usually by setting the actual line rate to somewhat less than the maximum achievable rate reported by the DSL modems during synchronisation (to accommodate the possibility that conditions change for the worse after synchronisation).
However, it is far from straightforward to determine whether or not such an additional margin for error should be built into the system for each individual line on a case by case basis, nor of determining the best way to do this (e.g. one easy way to achieve this is to place a line on a profile which is more stable than might seem to be necessary, etc.). Clearly if too much margin for error (e.g. to accommodate a line's noise environment becoming worse over time after synchronisation) is used on a particular line, then that line will be operating at less than its maximum achievable rate for no good reason. Similarly other lines might have a noise environment which changes much more significantly over time and as such the margin for error could be too small and then the line could still suffer from loss of connections, etc.
In order to try to find an optimum way of operating lines such that they achieve an optimum balance between stability and line rate (and latency, jitter, etc.) various techniques may be employed referred to generally as Dynamic Line Management (DLM). All of these techniques have in common that they need to have data about the operation/performance of the lines being managed. Generally speaking, the more data which the system has, the better it is able to find an optimum level of operation for each line to achieve a particular desired level of balance between stability and performance (e.g. speed/bandwidth, latency, jitter, etc.) This data is then processed by a DLM system which attempts to set/modify the operating parameters of each line to maintain each line operating with good stability at the maximum rate which the line can reliably sustain.
In order to collect this data, it is known to use devices known as data collectors or element managers. Each of these is responsible for a certain number of Digital Subscriber Line Access Multiplexors (DSLAMs) and/or Multiple Service Access Nodes (MSANs) or equivalent item (usually located within a local exchange or central office as they are known in the United States). These known devices then aggregate the data and forward it on to a central DLM system—typically a given access network will have just one centralised DLM system. In large access networks there may be several tens of element managers/data collectors each responsible for a hundred or so DSLAMs/MSANs with each of these having several hundreds of broadband connections being aggregated there. These two levels of aggregation can manage in total several million broadband connections. This in turn can give rise to a very large amount of data being collected, especially if a large proportion of the total amount of potentially useful performance/operational information about each line which is readily available to a DSLAM/MSAN is collected by the system for processing by the DLM system.
It is important to identify if the collected data on which decisions are being made are correct. The present inventors have determined that the most common way in which data is corrupted is by data going missing. The present inventors have further realised that in prior art systems in which the DLM system includes a central point which collects lots of information about individual lines and then makes decisions based on the collected data, it is difficult for the DLM system to ascertain if it has actually received all of the data which it is supposed to have received.
WO 2006/076518 describes a system of the type generally discussed above in which a central DLM management function collects operational data from a number of different elements within a DSL access network system and makes decisions about the correct profile to apply to each individual DSL connection based on that collected current data together with historical data from a historical data database. The key aspect of this system is that unlike most conventional DLM systems, instead of just relying on physical and/or data link layer metrics, this system additional looks at network and higher layer metrics when making decisions about appropriate profiles to choose for DSL connections. However, there is no discussion of the possibility that information received by the central DLM management function might be incorrect, let alone any suggestions for how to detect that such received information is incorrect (e.g. because some of the data that should have been collected is missing). Therefore, it fails to disclose a file check module comprising a receiver for receiving received data information from a management module (e.g. the DSL control system 102 or the decision model 130 thereof) specifying what data the management module has received and a comparator for comparing the received data information with data from a line status database (storing status data about individual lines—e.g. indicating which lines are set up to carry DSL connections and which are not) to generate comparison data (e.g. identifying missing data), and an output for outputting the generated comparison data.
EP 2 107 779 is an earlier patent application of the present Applicant which also deals with a centralised DLM system along the lines generally described above. Again there is no discussion or realisation of the problem which is tackled by the present invention. Thus, there is no discussion of the possibility that information received by the central DLM management function might be incorrect, let alone any suggestions for how to detect that such received information is incorrect (e.g. because some of the data that should have been collected is missing). Therefore, it fails to disclose a file check module comprising a receiver for receiving received data information from a management module (e.g. the management device 100) specifying what data the management module has received and a comparator for comparing the received data information with data from a line status database to generate comparison data (e.g. identifying missing data), and an output for outputting the generated comparison data.